Detailed learning i2pd worthy of respect. This article is close in spirit to router administration skills, but is devoted to a slightly different, but important topic: a set of tools that includes a number of useful utilities. i2pd-tools, ladies and gentlemen!
keygen – key generation
vain – generating keys using a template (miner of beautiful addresses)
keyinfo – key information
b33address – getting the address for the encrypted LeaseSet
regaddr – registration of a short domain in the .i2p zone
regaddr_3ld – registration of a third-level domain in the .i2p zone
regaddralias – binding a short domain to new keys
offlinekeys – using temporary keys for security purposes
routerinfo – router information
x25519 – generation of encryption keys
i2pbase64 – encoding information in base64 and decoding it
Compiling utilities
As usual, everything interesting awaits you in the official git repositories. At the core there is an English-language description with brief and most often understandable instructions, but that’s why it’s an article: now about the same thing, but in more detail in Russian.
Let's start with assembling binary files: first, download the repository to your device. The cloning command looks the same on all operating systems: git clone --recursive https://github.com/purplei2p/i2pd-tools. To install dependencies you need to run the script dependencies.sh. It is assumed that a C++ compiler and a make build program are already available, so dependencies refer exclusively to the boost and openssl libraries.
If you are just starting out in the field of building programs from source code, install git, the g++ compiler and the make build system with a command like this: sudo apt install git g++ make. For Windows users, everything is a little more complicated - you need to install a shell MSYS2, and then run the command from it: pacman -S git make mingw-w64-x86_64-gcc. The script for installing dependencies also runs in MSYS2 (if the script does not want to run, you need to make it executable with a simple command chmod +x dependencies.sh). When everything is ready, we start the build with the command make.
Good news: recently for Windows are published ready-made binaries, so if manual assembly seems overwhelming, use them.
keygen
When specifying non-existent keys in the tunnel configuration file, new ones are automatically created. In most cases this is convenient. However, if you need to know the address in advance, or perform some additional manipulations with the key, you should use the keygen utility. Usage is extremely simple: run keygen indicating the desired name for the new keys. By default, the current signature type EDDSA-SHA512-ED25519 (coded 7) is used, which is also the default type when creating keys by the I2P router itself. If you need to obtain a key with a different type of signature, it should be specified at startup after the file name. You can specify both the type name and its number. Designations are given in the file README.
vain
It is extremely rare to see an address that is even somewhat readable in the keygen output (because it is just a hash). For addresses with a human-readable beginning, there is a separate vain utility (vanitygen). The self-explanatory name (vanity) hints at the main application of the address miner. Of course, in addition to vanity, an address with a memorable beginning also has a practical benefit: it is easier to recognize by eye.
When launched without parameters, we see information about usage. Searching by string pattern is always carried out from the beginning of the address. If you need a more flexible search, or not from the beginning of the line, you should use regular expressions. Please note that searching against a regular expression is slower than searching against a regular string value. The default number of threads matches the number of cores on the computer, but can be manually set via the parameter -t (--threads).
Patterns of up to 6 characters are found almost instantly, but as the search string increases, the time grows exponentially. A small sign with the approximate time spent is given in the file README. At the time of publication of the article, vain only supports keys with the signature type EDDSA-SHA512-ED25519 (7), which is used by default on the network.
keyinfo
The i2pd web console is not always convenient to use to obtain information about keys. First of all, because it displays only the private keys currently in use. Secondly, not exhaustive information about the keys is provided. For example, there is no explicit indication of the encryption and signature type.
Possible parameters: -v – from "verbose", detailed output; -d – from “destination”, output only the full address in base encoding64, -b – from "b33" ("bb32"), displaying the address for the encrypted LeaseSet (for more information about encrypted LeaseSets, read article).
When transferring a private key without additional parameters, its intranet address (domain) is displayed. Detailed output displays the full address (a set of all cryptographic identifiers).
Pay attention to the "Destination Hash" field. This is a daily changing value by which the endpoint selects a place to publish information about itself, and the client determines the flood file to contact for this address. Read more about how the address storage hash changes every day and why this is critical from a security perspective. article.
b33address
keyinfo with flag -b calculates the address for the endpoint with the encrypted LeaseSet. b33address does the same thing, but does not accept a file with keys, but a full address encoded in base64. To use encrypted LeaseSets (which are called b33 or bb32, which are the same thing), it is recommended to use signature type 11. The b33address utility only works with this. 
In the screenshot, a key is generated, then its bb32 address is requested via keyinfo. To get the full address, keyinfo is used again. The keyinfo output was copied and then passed to b33address. The utility reported the address that will be used for the encrypted LeaseSet, and also displayed today's storage hash. As you can see, the values coincide with those provided by the keyinfo utility, i.e. b33address functionality is similar to keyinfo -b, but differs in the format of the received value.
regaddr
To register short human-readable domains like “site.i2p” you need to visit the registrars reg.i2p and stats.i2p (the first is from the Russian-speaking community PurpleI2P, the second is from the English-speaking Java router team).
Both registrars work on a similar principle: you provide your full address to which the desired domain will be linked, as well as a cryptographic signature of the stated desire. The signature is verified by the key from the full address. Such a request has a standard form and is generated by the regaddr utility (from version 2.37.0 i2pd supports generating a registration string via the web console). The syntax of the utility is simple: first the file with the keys, then the desired domain.
The operation of the regaddr utility is simple, as is the syntax of the registration line: first comes the desired domain, then the full address to which it will be linked, and at the end of the line - the signature of the desired domain. The full address is highlighted in blue in the screenshot. For clarity, the full address is also obtained by the keyinfo utility with the flag -d. The signature is highlighted in red.
Upon receiving such a string, the registrar checks the validity of the signature and, if the declared domain is free, registers it. For example, you can use the utility verifyhost, which is used by reg.i2p. When used in bash, you must escape the exclamation mark so that it is interpreted as part of a string and passed to the utility (or enclose the entire expression in quotes).
The signature is correct, so verifyhost did not throw any errors and returned a value of zero.
regaddr_3ld
I2P supports third-level human-readable domains. Their registration occurs in a similar way, but the string is generated a little more complicated - in three steps. Generating a registration string for a third-level domain is not possible through the web console and being implemented exclusively through the regaddr_3ld utility.
First, the desired third-level domain is signed with the subdomain key:
./regaddr_3ld step1 sub_domain.dat sub.domain.i2p > step1.txtThen the subdomain string is signed with the key of the main domain:
./regaddr_3ld step2 step1.txt domain.dat domain.i2p > step2.txtFinally, the application for a third-level domain, signed with the key of the main domain, is signed with the key of the third-level domain:
./regaddr_3ld step3 step2.txt sub_domain.dat > step3.txtIn the example given, the registration string is in the file step3.txt.
regaddralias
To change the keys to which a short domain is attached, use the regaddralias utility. To implement the opportunity, you must have old keys on hand (and not just new ones). The program is passed the name of the file with the new keys, the file with the old keys, and the domain itself as the last parameter.
The screenshot highlights the keywords of the domain rebinding alias to new keys: a new full address is specified indicating the previous full address and signatures are attached to all of this.
offlinekeys
I2P has the concept of offline keys, which allows you to store permanent keys in a secure location. In other words, the main key is stored in a secure place, and the server uses a temporary one that expires after a specified number of days. If it is compromised, after a specified period of validity, you can confidently say that your network address again belongs only to you. Offline keys are discussed in detail in a separate section. article.
In the screenshot, the main key and its address are highlighted in red, and the temporary key, which is marked “Offline signature” and the same address, is highlighted in blue.
routerinfo
The I2P router stores information about known routers in the netDb directory. These routers are then used to build transit tunnels. The file that is the router identifier is called RouterInfo (RI). It includes information about cryptographic keys and the IP address (if it is published and accessible externally).
Flag -p displays the port (by default, only the IP address is displayed). Flag -f prints a rule for the iptables firewall to allow outgoing connections to a specific I2P router (for paranoid cases when all outgoing connections are denied). Parameter -6 adds an IPv6 address to the output if it is present. 
x25519
x25519 – a utility for generating a pair of encryption keys of the same name, outputting the result in base64 encoding. At the time of publication of the article, it is used in encrypted LeaseSets with authorization.
i2pbase64
Almost every point in this article mentioned some kind of information, which by default is binary (binary, unreadable machine code). For example, cryptographic keys and hashes. To make binary information easier for humans to perceive, as well as easily transmitted in text form, encoding is almost universally used in I2P Base64. The base64 alphabet in I2P differs from the general standard by two characters: + is replaced by -, A / on ~. This is due to the use of base64 strings in the web browser, where + And / are special characters: human-readable short domains are written to the local router database via a browser by opening special links (addresshelper).
The screenshot shows an example of encoding text information and then decoding it back into text. The utility works in the same way with any binary files such as images or videos. There is no direct practical purpose for i2pbase64 in i2pd-tools. This is a highly specific utility for exotic tasks, for example, manual encoding of third-party keys.
The famtool utility was not covered in the article for a simple reason: family is an additional identifying feature of the router. In a concept that only a few believed in, including zzz (the leading developer of the Java router), family is specified by respectable users so that routers of the same administrator do not appear together in the same tunnel. As it is not difficult to understand, this option is never used by anyone, and family is not used even more so by malicious people who want to capture as many tunnels as possible to try to monitor the network. While practically meaningless, the famtool tool is not trivial to use, so it is omitted from this material.
